Business Analyst Community & Resources | Modern Analyst

What Is Fault Tree Analysis (FTA)?

Adrian M. — Sun, 19 Oct 2025 23:23:00 GMT

Fault Tree Analysis (FTA) is a systematic, top-down method used to identify the root causes of potential system failures. It visually maps how different component failures, human errors, or process faults can combine to produce an undesirable event—known as the “top event.”

FTA helps analysts understand why a failure might occur, how likely it is to occur, and what corrective or preventive actions can reduce that likelihood. It is widely used in safety-critical industries such as aerospace, healthcare, automotive, manufacturing, and finance (for risk modeling).

When would you choose impact mapping over user stories to scope an MVP?

Adrian M. — Tue, 22 Jul 2025 04:01:00 GMT

Interview Sound-bite

“I reach for impact mapping at the discovery stage—especially when stakeholders propose an ‘MVP’ that’s really a shopping list of features. In a 90-minute workshop we visualise the business goal, actors, and behavioural impacts. Anything that doesn’t trace directly to the goal is deferred. Only then do we decompose the surviving deliverables into user stories with INVEST attributes. This ensures our MVP is outcome-driven, not backlog-driven, and gives executives a clear line of sight from release scope to business value.”

The Details

Impact mapping is a strategic framing technique; user stories are tactical delivery units.
Choose impact mapping first—instead of jumping straight into user-story writing—when you must clarify why and who before debating what. Typical triggers:

Situation	Why Impact Mapping Wins
Vague or competing business goals	Links every deliverable to a single, measurable objective, exposing mis-aligned stakeholder expectations early.
Multiple actor groups with different behaviors	Forces the team to enumerate who must change what behavior to achieve the goal—something user stories assume is already understood.
Risk of feature bloat	The Goal → Actor → Impact → Deliverable flow surfaces “nice-to-have” ideas that don’t support a quantifiable impact and lets you cut them before they hit the backlog.
Green-field or pivot projects	Provides a lightweight strategic roadmap when historic data or detailed requirements are scarce.
Executive visibility required	The single-page map is easier for sponsors to grasp than dozens of granular stories.

When to Transition to User Stories

Once the Goal–Actor–Impact layers are stable.

After the MVP deliverables column fits inside the team’s capacity and timeline.

When detailed acceptance criteria, edge cases, and UI specifics must be captured for development and testing.

Rule of thumb - Use impact mapping to decide if a feature deserves to exist; use user stories to decide how that feature will work.

What is Impact Mapping?

Adrian M. — Tue, 15 Jul 2025 04:27:00 GMT

Impact Mapping is a lightweight strategic‐planning technique, created by Gojko Adzic, that draws a visual mind-map linking business goals to the smallest set of deliverables needed to meet them. By answering four cascading questions—Why (Goal) → Who (Actors) → How (Impacts) → What (Deliverables) - it ensures every backlog item exists for a measurable, traceable reason.

Impact Mapping gives analysts a fast, collaborative lens for tying every requirement to a tangible business outcome, letting teams cut waste and steer products toward real, measurable value.

Core Structure

WHY – Goal: One quantified objective with a deadline (e.g., “Reduce average refinance cycle from 22 days to 15 by Q4”).

WHO – Actors: People, systems, or partners that can help or hinder reaching the goal.

HOW – Impacts: Specific behavioral changes we want from each actor (e.g., “Borrowers upload documents within 24 h”).

WHAT – Deliverables: Features, process tweaks, or policy changes most likely to trigger those impacts.

Typical Workshop Flow

Convene sponsor, BA, UX, dev, and ops in a short workshop.
Agree on a single north-star goal and verify its metric.
List potential actors; rank by leverage.
For each actor, brainstorm desired impacts; challenge with “Will this behavior really move the metric?”
Ideate deliverables; delete anything without a clear impact path.
Slice the map vertically into thin, testable releases; translate priority branches into epics and user stories.
Track progress by monitoring the impact metric—not just feature completion—and revisit the map as evidence changes.

Why It Matters to Business / Systems Analysts

Impact Mapping compresses strategy and delivery onto one page, replacing speculative scope with testable hypotheses. It prevents gold-plating, supplies a built-in traceability matrix, and promotes outcome-based KPIs—exactly the artefacts analysts need for governance, budgeting, and benefits realization.

Example

A mortgage lender wanted first-pass underwriting approvals to hit 90 %. Actors were underwriters, borrowers, and the credit-bureau API. Desired impacts included “borrowers attach complete income docs” and “underwriters spend <30 min per file.” The map highlighted three high-leverage deliverables: a mobile document-scanner with completeness checks, a credit-pull microservice, and an underwriter workload dashboard. Focusing only on these behavior-changing items lifted first-pass approvals from 72 % to 94 % in three months—without adding staff.

What is YAGNI and Why should a Business Analyst care?

Adrian M. — Wed, 10 Apr 2024 00:20:00 GMT

YAGNI stands for "You Aren't Gonna Need It." It is a principle in software development that suggests not to add functionality or implement features until they are actually needed to solve a problem or fulfill a requirement. In essence, it advocates for simplicity and avoiding speculative development based on anticipated future needs.

The YAGNI principle originated from extreme programming (XP) and agile software development methodologies, closely related to the concept of MVP (Minimum Viable Product).. Its core idea is to prevent over-engineering or adding unnecessary complexity to the software by only implementing what is currently necessary.

As a business analyst, YAGNI holds several key implications that are essential to understand:

Focus on Essential Requirements - YAGNI encourages prioritizing and focusing on gathering and documenting only the essential requirements that directly address the immediate needs of the business.

Efficient Resource Allocation - By adhering to YAGNI, the analyst can help ensure that resources, including time, budget, and personnel, are allocated efficiently.

Flexibility and Adaptability - YAGNI promotes a mindset of flexibility and adaptability in response to changing business needs and priorities. As business analysts, we need to be responsive to evolving market conditions, customer feedback, and internal stakeholder requirements.

Effective Collaboration with Development Teams - YAGNI fosters collaboration between business analysts and development teams by ensuring alignment on prioritized requirements. By clearly communicating the rationale behind prioritized features and avoiding the inclusion of unnecessary requirements, analysts can facilitate a shared understanding between business and technical stakeholders.

Cost-Effective Solutions - YAGNI promotes the delivery of cost-effective solutions by avoiding over-engineering and unnecessary complexity.

What is TIMWOOD?

Adrian M. — Tue, 12 Dec 2023 04:26:00 GMT

Also known as the “7 Wastes”, TIMWOOD is an acronym in Lean processes that represents seven common types of waste that organizations aim to identify and eliminate to improve efficiency. Each letter in the acronym corresponds to a specific form of waste:

T - Transportation - The unnecessary movement of materials, goods, or information. Excessive transportation can lead to delays, damage, and increased costs.

I - Inventory - Excessive inventory or stock beyond what is required for immediate use. High inventory levels tie up capital and can lead to obsolescence and waste.

M - Motion - Unnecessary movements or actions by people, machinery, or equipment. Reducing unnecessary motion helps improve efficiency and reduces the risk of injuries or fatigue.

W - Waiting - Idle time or delays in a process where no value is being added. Waiting times can lead to increased lead times, longer cycle times, and reduced overall productivity.

O - Overproduction - Producing more than what is needed or producing items before they are required. Overproduction can lead to excess inventory, increased storage costs, and potential waste.

O - Overprocessing - Performing more work than is necessary to meet customer requirements. Overprocessing can involve using more resources, time, or effort than needed to deliver the desired output.

D - Defects - Any form of errors, mistakes, or defects in a product or service that require rework or correction. Defects can lead to increased costs, customer dissatisfaction, and wasted resources.

The TIMWOOD concept is a tool used in Lean processes to help organizations identify areas of waste in their processes. By recognizing and addressing these forms of waste, businesses can improve efficiency, reduce costs, and enhance the overall value delivered to customers. The goal is to create a more streamlined and effective operation with minimal waste throughout the entire value stream.

An agile business analyst can benefit from understanding the TIMWOOD concept by applying it as a diagnostic tool to identify and eliminate waste within business processes. By recognizing instances of Transportation, Inventory, Motion, Waiting, Overproduction, Overprocessing, and Defects, a Business Analyst gains insight into inefficiencies and areas where value is not being maximized. By addressing these forms of waste, the Business Analyst helps create more effective and customer-focused business processes, aligning efforts with Lean principles to eliminate unnecessary activities and promote continuous improvement.

What are Lean Processes?

Adrian M. — Tue, 12 Dec 2023 03:59:00 GMT

Lean processes are a set of principles and practices focused on minimizing waste, improving efficiency, and delivering value to customers. Originally developed in the manufacturing sector, Lean principles have been widely adopted across various industries, including software development, healthcare, and services. The core idea of Lean is to create more value for customers with fewer resources.

Lean principles can significantly impact the role of a Business Analyst (BA) by influencing how they approach requirements gathering, process analysis, and overall collaboration within the organization.

Lean processes, often associated with Lean manufacturing, are a set of principles and practices focused on minimizing waste, improving efficiency, and delivering value to customers. Originally developed in the manufacturing sector, Lean principles have been widely adopted across various industries, including software development, healthcare, and services. The core idea of Lean is to create more value for customers with fewer resources.

Key principles of Lean processes include:

Value - Identify and define what constitutes value from the customer's perspective. Value is anything that the customer is willing to pay for.
Value Stream - Map out the entire value stream for a product or service, including all the steps and processes from concept to delivery. This helps in visualizing the end-to-end flow of value.
Flow - Optimize the flow of work through the value stream by eliminating bottlenecks, reducing delays, and ensuring a smooth and continuous process.
Pull - Implement a pull system, where work is pulled into the process based on actual customer demand rather than being pushed through based on projections. This helps in minimizing overproduction and excess inventory.
Perfection - Strive for continuous improvement and perfection. This involves an ongoing process of identifying and eliminating waste, improving efficiency, and enhancing overall quality.
Waste Elimination (Muda) - Identify and eliminate various forms of waste that do not add value to the customer. There are seven types of waste in Lean, often remembered by the acronym TIMWOOD: Transportation, Inventory, Motion, Waiting, Overproduction, Overprocessing, and Defects.
Continuous Improvement (Kaizen) - Foster a culture of continuous improvement, where small incremental changes are made regularly to improve processes and outcomes. This involves everyone in the organization and is not limited to a specific department or level.
Standardized Work - Establish standardized work procedures that are clear, repeatable, and continuously improved. This helps in reducing variation and ensuring consistency.

Here are some of the ways Lean principles can impact the business analyst's role:

Waste Elimination - Business Analysts should actively identify and eliminate waste in processes. This includes removing unnecessary documentation, redundant activities, and requirements that do not directly contribute to the value delivered to the customer.
Collaboration and Cross-Functional Teams - Business Analysts may work closely with developers, testers, product owners, and other stakeholders to ensure a holistic understanding of the value stream and to facilitate smooth workflows.
Visual Management - Business Analysts can use visual management tools, such as Kanban boards or other visual aids, to communicate the status of requirements, projects, and priorities. This helps in making information easily accessible and transparent to the entire team.
Standardized Work - Business Analysts can contribute by creating clear and standardized requirements documentation, making it easier for the development team to understand and implement.
Kaizen - Business Analysts should actively participate in and promote a culture of continuous improvement. Regular retrospectives and feedback sessions can provide insights for improving processes, communication, and collaboration.

Lean processes empower Agile Business Analysts to streamline processes, eliminate waste, and prioritize customer value, fundamentally transforming their approach. By focusing on efficiency, continuous improvement, and cross-functional collaboration, Lean methodologies guide Business Analysts in delivering requirements that align closely with customer needs, reducing unnecessary documentation, and fostering a culture of adaptability.

What is an Agile Business Analyst?

Adrian M. — Tue, 12 Dec 2023 03:45:00 GMT

In general terms, an agile business analyst is a business analyst who performs their craft within an agile environment, either as a member of an agile team or part of the program/portfolio team. Realistically, a business analyst cannot call themselves agile just because they’re on an agile team. To be an agile business analyst one must adapt their traditional business analysis techniques and mindset with the principles and practices of agile methodologies.

Here are some of the characteristics of an agile business analyst:

Engages in an iterative and incremental project lifecycle, with the ability to adapt to changing requirements and priorities throughout the development process.
Focuses on lightweight documentation, using user stories and acceptance criteria to capture requirements in a more concise and easily digestible format.
Embraces change and is adaptable to evolving requirements, with the ability to reprioritize and adjust focus in response to customer feedback and shifting business needs.
Encourages frequent and continuous customer collaboration throughout the development process, with regular feedback sessions and demonstrations.
Emphasizes collaboration and teamwork, often working closely with cross-functional teams that include developers, testers, and other stakeholders.
Prioritizes delivering minimum viable products (MVPs) or increments of value in short, fixed time frames known as sprints.

Some of the responsibilities of an agile business analyst include:

User Stories - collaborate with stakeholders to define and prioritize user stories, which are concise descriptions of functionality from an end-user perspective.
Prioritization - assist in prioritizing features and user stories based on business value, customer needs, and project constraints.
Communication - act as a bridge between technical and non-technical stakeholders, translating business needs into technical requirements and vice versa.
Backlog Refinement - participate in backlog refinement sessions to ensure that the product backlog is well-maintained, prioritized, and ready for upcoming sprints.
Documentation - document requirements using user stories with acceptance criteria.

The agile business analyst must also be flexible enough to take on responsibilities of other agile team members such as the roles of: product owner, scrum master, and tester.

While most of the traditional business analysis skills are very much applicable in an agile environment, to transition to an agile business analyst role the practitioner should:

Learn and adopt lean and agile principles, practices, and most importantly, mindset.
Familiarize themselves with agile methodologies such as Scrum, Kanban, Extreme Programming, and the Scaled Agile Framework (SAFe).
Understand the basics of a Scrum team such as its key roles such as product owner, scrum master, and product manager and it’s ceremonies including daily stand-ups, print planning, sprint reviews, and retrospectives.
Adopt common artifacts used in agile methodologies such as product backlog, epics, user stories, and acceptance criteria.
Familiarize themselves with agile tools such as Jira, Azure DevOps, and VersionOne.

So, what is an agile business analyst? In summary, an agile business analyst plays a crucial role in ensuring that the development team delivers value to the customer by aligning the work with business goals, fostering collaboration, and adapting to changing requirements throughout the agile development process.

What are your thoughts?

What are the SAFe Lean-Agile Principles?

Adrian M. — Tue, 14 Nov 2023 04:07:00 GMT

The Scaled Agile Framework (SAFe), a leading framework for business agility, is based on a set of principles, mostly derived from the lean-agile discipline. These principles include:

Take an Economic View

Identify the economic trade-offs and make decisions based on economic principles.
Consider the full value stream and its operation within the approved budget

Apply Systems Thinking

Optimize the whole system, rather than focusing on individual components.
Consider the interactions and dependencies among various components of the entire system.

Assume Variability; Preserve Options

Embrace uncertainty and variability, and maintain the ability to make decisions at the last responsible moment.
Identify multiple requirements and design options for a longer period in the development cycle.

Build Incrementally with Fast, Integrated Learning Cycles

Build in small, incremental steps with feedback loops to allow for continuous learning and improvement.
Integrate completed code and test frequently to ensure quality.

Base Milestones on Objective Evaluation of Working Systems

Base milestones on the achievement of business value and objective evaluation of working systems.
Evaluate progress often, throughout the development life cycle.

Make Value Flow Without Interruptions

Visualize and limit WIP (work in progress).
Reduce batch sizes and manage queue lengths.
Minimize handoffs and dependencies.

Apply Cadence, Synchronize with Cross-Domain Planning

Aligning development cadence across multiple teams.
Provide regular opportunities for cross-domain planning.

Unlock the Intrinsic Motivation of Knowledge Workers

Encourage a culture of innovation, collaboration, and ownership.
Support the intrinsic motivation of knowledge workers with autonomy, mastery, and purpose.

Decentralize Decision-Making

Push decision-making to the lowest level possible, while ensuring role clarity.
Allow teams and individuals to make decisions in their areas of expertise.

Organize around Value

Form align teams and align them to value streams.
Establish technology portfolios and development value streams.

What is WAgile?

Adrian M. — Mon, 14 Aug 2023 01:29:00 GMT

WAgile is a term coined to describe software development processes which employ a combination of Waterfall and Agile methodologies. While there are not defined standards for WAgile, most organizations which find themselves using this hybrid approach do so by using agile constructs for the development teams aka scrum teams while also employing waterfall planning methods at the portfolio or program levels.

With waterfall methodologies being considered legacy or outdated and with agile methodologies being viewed as the modern way to develop software, why WAgile?

Well, most organizations do not make the conscious decision to use WAgile hybrid approaches but rather their WAgile environment is the result of a waterfall organizations' decision to become agile only to discover that demands placed on them by management, shareholders, or investors do not allow them to adopt a pure agile approach.

Scenarios which may require a WAgile approach include:

Projects involving strict regulatory or compliance requirements requiring a more structured and more documented approach
Large and complex projects where early planning and design stages follow a more traditional Waerfall approach to ensure comprehensive requirements gathering and design
When dealing with clients which expect or are more comfortable with traditional project management methods, a WAgile could satisfy the contractual obligations
Organizations which use a yearly budget cycle required by regulatory reporting, such as publicly traded companies governed by specific accounting standards
When contractual obligations or leadership expectations require strict adherence to scope, budget, and timelines
When moving directly to an agile approach is not possible, WAgile can provide a bridge or a stepping stone to future transition

Finding themselves in a hybrid environment, companies would do well to accept the WAgile approach by leveraging the best of both worlds and tailoring their specific methodology based on their specific needs. Some WAgile processes may be skewed more towards agile while others may be more skewed towards waterfall. Neither approach is wrong if it meets the needs of the organization..

You may hear, from agile purists, comments such as “WAgile is bad”, “Move away from WAgile”, “Is WAgile even a thing?” , “WAgile creates confusion”, “WAgile is ugly”, “WAgile is worse than waterfall”, etc.

Should you listen to them?

Sure, listen to them… but… make up your own mind. Don’t let yourself be persuaded by opinions but by the requirements that your organization is faced with.

In a nutshell, if WAgile works then it works.

What is Timeboxing (in Agile)?

Adrian M. — Sun, 09 Jul 2023 22:22:00 GMT

Timeboxing sits at the core of most agile development methodologies helping the teams stay focused on achieving concrete results within prescribed time or planning cycles. You are most likely already familiar with standard agile timeboxes such as a sprint or a program increment.

Timeboxing is the practice of setting a fixed period of time during which very specific objectives are planned to be achieved. The essence of timeboxing is to focus on achieving specific objectives and not simply focusing on a set of tasks. Without this practice, teams can fall into the Parkinson’s Law trap aka the curious expansion of work to fill all the allotted time span.

The Dynamic Systems Development Method (DSDM) structured timebox is comprised of three main steps boxed between the kick-off and the close-out of the timebox:

Kick-off

Investigation

Refinement

Consolidation

Close-out

In agile project management, the benefits of timeboxing are quickly apparent:

Focus on delivering value

Predictability and transparency

Team accountability

Continuous improvement

Prioritization of objectives

Adaptability and flexibility

Collaboration and teamwork

Enhanced productivity and efficiency

What is the Dynamic Systems Development Method (DSDM)?

Adrian M. — Sun, 09 Jul 2023 20:31:00 GMT

The Dynamic Systems Development Method or DSDM is an agile project delivery methodology which covers the entire software development lifecycle. It was originally created to provide more structured governance and discipline to teams using Rapid Application Development (RAD). The DSDM is owned and managed by the Agile Business Consortium, an independent, non-profit, professional organization focused on advancing business agility. The Agile Business Consortium publishes the DSDM Project Framework, available online.

The DSDM framework sits on the foundation of eight core principles:

Principle 1: Focus on the business need

Principle 2: Deliver on time

Principle 3: Collaborate

Principle 4: Never compromise quality

Principle 5: Build incrementally from firm foundations

Principle 6: Develop iteratively

Principle 7: Communicate continuously and clearly

Principle 8: Demonstrate control

Here's a high-level view of the DSDM Project Phases:

Craig Cockburn, CC BY-SA 3.0, via Wikimedia Commons

To accomplish its goal of helping teams to deliver better software and to mitigate project risks, the Dynamic Systems Development Method (DSDM) relies on a number of core techniques and practices including:

Timeboxing

Modeling

Prioritizing using MosCoW

Prototyping

Iterative Development

The DSDM Project Framework defines all the components of a software development lifecycle including:

Core Practices

Roles and responsibilities

Process

Peoples, Teams, and Interactions

Requirements and user Stories

Project Planning and Control

What is Continuous Testing (CT)?

Adrian M. — Sat, 11 Mar 2023 23:08:00 GMT

Continuous Testing (CT) is a software testing practice that involves testing early, testing often, and testing throughout the entire software development process. It is an approach to testing in which automated tests are run throughout the software development lifecycle (SDLC), from the initial stages of code development to the final stages of deployment.

The goal of continuous testing is to provide rapid feedback on the quality of the software being developed, allowing for quick identification and remediation of defects, reducing the overall cost and time of development. CT involves integrating automated testing tools into the software development practice, which helps to ensure that testing is performed often, consistently, and comprehensively.

Continuous testing helps to identify defects early in the development cycle, reducing the cost and time of fixing defects later in the cycle. It also helps to improve software quality, reduce the risk of errors, and increase the speed of software delivery. By automating the testing process, continuous testing allows developers to focus on coding, while the testing tools automatically validate the code, ensuring that it meets the required quality standards.

What are the benefits of Continuous Testing?

Continuous Testing provides many benefits to software development organizations, including:

Early Defect Detection: Continuous testing allows for early detection and resolution of defects, reducing the time and cost of fixing issues later on in the software development lifecycle.
Improved Software Quality: Continuous testing ensures that software is tested thoroughly and consistently, resulting in higher quality products that meet the user's requirements.
Faster Time-to-Market: By automating the testing process, continuous testing speeds up the development cycle and allows for quicker release of software.
Enhanced Collaboration: Continuous testing promotes collaboration between developers, testers, and other stakeholders, resulting in better communication and a shared understanding of the product.
Reduced Risk: The practice of continuous testing helps to identify and mitigate risks in the system, thus improving the overall reliability and security of the software.
Improved Customer Satisfaction: Continuous testing results in higher quality software that meets the user's requirements, leading to increased customer satisfaction and loyalty.
Increased Efficiency: By automating testing, continuous testing saves time and reduces manual efforts, enabling developers to focus on coding and improving productivity.
Reduced Costs: In addition to the above benefits, the use of continuous testing also has the added benefit of reducing the cost of software development through the reduction of manual testing efforts as well as through the reduction of software coding rework.

Overall, Continuous Testing helps to ensure that software development is efficient, effective, and meets the user's requirements, resulting in higher quality products and happier customers.

In summary, here are some quick points about continuous testing:

Continuous Testing is an important component of Agile's iterative and incremental approach to software development.
It enables teams to deliver high-quality software quickly, with frequent releases and updates.
Continuous Testing is integrated with other Agile practices, such as Continuous Integration and Continuous Delivery.
It helps to identify and fix defects early in the development cycle, reducing the cost and time of fixing issues later on.
Continuous Testing is used to ensure that the software is meeting the user's requirements, and that it is functioning as intended.
It involves automating the testing process and using tools to test the software continuously throughout the development cycle.
Continuous Testing enables teams to get feedback quickly and make adjustments to the software as needed, improving the quality of the product and increasing customer satisfaction.

What is Value Stream Management (VSM) in Agile?

Adrian M. — Mon, 13 Feb 2023 03:49:00 GMT

What are Value Streams

Before we dive into Value Stream Management, let’s first take a look at what a value stream is. Applied to organizations or groups whose goal is to deliver a product or service, the value stream refers to the totality of processes and activities required to bring value (the product or the service) to fruition from inception all the way to the customer. The value stream starts with the customer’s needs in mind and ends with bringing value to that customer.

What is Value Stream Management

Consider, for a second, two competing organizations whose goal is to bring the same value to the same set or type of customers. Both organizations have their own value streams to achieve this goal. Are these two value streams exactly the same? Are the processes, activities, procedures, and mindsets used within each company’s value stream identical? Probably not. The two value streams are most likely different and unique to each company.

The goal of each organization is to maximize the value they provide their customers while minimizing their cost. To this end, most organizations focus on continuous improvement of their value streams.

The practices or sets of techniques used by organizations to increase the flow of value, through their value streams, to their customers is called Value Stream Management (VSM).

Even simple or small organizations find themselves with multiple value streams and, in order to be as effective as possible, they must clearly define how to break down their organization into value streams and clearly define each of their value streams. This is the practice of Value Stream Management.

What are the Benefits of Value Stream Management

Value Stream Management helps organizations to purposefully put the customer at the center of what they do. In order to increase value to its stakeholders, companies must focus on maximizing value to their customers. A robust value stream management practice will help increase value by:

Measuring the efficiency of its processes

Eliminating waste from the processes

Avoid scenarios which could interrupt a value stream

Enabling more accurate value delivery estimates

Providing ability to make data-driven investment decisions

Ways to Support and Improve Value Stream Management

Not all organizations achieve the same maturity executing value stream mapping. What differentiates the best from the rest are a number of important aspects:

Value stream mapping - the practice of analyzing and clearing documenting (mapping) the processes and activities within each value stream. A better understanding of the “as-is” of each value stream enables the improvement of those value streams.

Value stream management platforms - by employing specialized VSM software, companies can more effectively and easily manage the performance of their value streams.

Agile: User Stories versus Epics, what's the difference?

Chris Adams — Fri, 10 Jun 2022 16:00:00 GMT

User Stories and Epics make up the essential building blocks of agile planning and development. They are closely related and, therefore, the differences are often misunderstood.

What is the difference between horizontal and vertical prototyping?

Chris Adams — Thu, 09 Jun 2022 16:07:00 GMT

Horizontal and vertical prototypes are sometimes used during the analysis and design phases of application development. They are useful for requirements elaboration and visualization, but can present some pitfalls. As long as analysts and teams are aware of the pitfalls to avoid, the pros of using prototypes generally far outweigh the cons. The type of prototype that should be used (horizontal prototype versus vertical prototype) depends on the specific goals of the team and the stage within the analysis and design process.

Compare a user story versus a use case. What are the essential elements of each? When would you use one versus the other?

Chris Adams — Sat, 08 Jan 2022 22:08:00 GMT

The essential elements of a user story are:

The user
Statement of what the user needs to accomplish
Why the need to accomplish this

The essential elements of a use case are:

The Actor carrying out the use case
Summary of the use case
Success criteria
Scenario detailing the steps the Actor follows to achieve the success criteria.

How do you feel about peer reviews of your business analysis work?

Chris Adams — Mon, 08 Nov 2021 16:38:00 GMT

If you’re not familiar with peer reviews, it’s a process where Business Analysis team members review one person’s work and provide feedback on it. For example, a group of user stories are shared with the team for pre-reading before a peer review meeting. In the meeting, each user story is discussed with team members providing feedback. This is an opportunity for the author to get suggestions about ambiguous wording and structure. It’s also an opportunity to get input from peers based on their knowledge of the business that can be helpful in making the user stories more robust.

As a candidate being interviewed, this question is about aspects of your personality, working style, and understanding the value of peer reviews.

What is an Impact Map, what makes it robust, and why should an experienced BA know how to create one?

Chris Adams — Fri, 10 Sep 2021 20:45:00 GMT

Impact maps are a powerful tool in the agile BA toolkit. First introduced by Gojko Azdic, a Strategy Consultant, in 2012, Impact Maps (IM) are a fast and straightforward strategic planning tool. They provide a high-level graphic view of business goals and how they may be achieved. Several free and paid tools can be used for creating Impact Maps. It facilitates collaboration between technical teams and business stakeholders as well as being an enabler for getting all stakeholders aligned regarding goals and the strategies for achieving them.

How do solve the problem of endless meetings with few results?

Chris Adams — Fri, 07 May 2021 16:10:00 GMT

There are a couple of ways you can ensure that your meetings are producing results rather than endless discussion. Here are two options that can work, each catering to a different organizational environment.

What is a Scrum of Scrums and what are its benefits?

Chris Adams — Mon, 03 May 2021 21:19:00 GMT

You manage a team of Project Managers and Business Analysts.They are all assigned different projects, but you come to realize they all intersect at one business application.

All teams conduct their meetings throughout the project to ensure it's going according to the project charter or their sprint goals. Some are using status meetings, and others are running daily scrums.

How do you ensure synchronization among the teams and that an accidental change does not compromise the business application? That there are no impacts or impediments to a smooth delivery? What is your approach?

In Agile, does the term Developer mean Programmer?

Chris Adams — Wed, 06 Jan 2021 23:00:00 GMT

When you let yourself forget about software for a moment, you'll begin to realize there are other types of developers who are not close to the Technology Department and have no clue about C++, Python, or PHP.

Some know neighborhoods best because they are real estate developers. Others understand curriculums because they are academic program developers. And some want to reach new markets, so you guessed it, the company hires a market developer to handle the responsibilities of getting into, establishing, and growing that market segment.

What is your "Definition of Done"?

Chris Adams — Wed, 02 Dec 2020 20:30:00 GMT

The Scrum Guide's definition of Done (DoD) is shared and agreed upon within the Scrum team. An item is "Done" when a backlog item/increment is potentially shippable. Where, at the end of a Sprint, you must have something complete and ready to ship, but shipping is not required.

List the steps you would take to bring a product from idea to deployment and beyond.

Chris Adams — Sun, 08 Nov 2020 20:14:00 GMT

Some of these steps could be combined, pared down, or avoided altogether depending on the demands of the project and complexity of the product or application. Use the minimum amount of tools, models, and specifications needed to communicate the necessary information to the coders in a way that ensures the final product meets the expectations of the customer and is defect free. Once might refer to this as “just enough documentation” – not too much, but not too little.

What is a Stakeholder Story and how does it compare to a User Story?

Chris Adams — Sun, 12 Apr 2020 19:59:00 GMT

A User Story is perhaps the most widely used Agile technique. It is used to capture product and system requirements from the perspective of the user. Is it the fundamental building block of the Product Backlog. A stakeholder story expands the scope of requirements to non-users of the system.

What is an Agile Mindset?

Chris Adams — Sun, 08 Dec 2019 21:31:00 GMT

Agile is a term that was first coined in 2001 with the creation of the Agile Manifesto. Agile has grown enormously in the last two decades and is now used by thousands of organizations and teams around the world. With that growth in popularity many variations have emerged – new frameworks like Kanban and SAFe have been created and thousands of books have been written on different elements of Agile.

What is Program Increment Planning as it applies to the Scaled Agile Framework?

Chris Adams — Mon, 11 Nov 2019 18:34:00 GMT

Program Increment (PI) Planning is one of the biggest and most important events in the Scaled Agile Framework (SAFe). It aims to set the direction and activities for the Release Train’s next 8-12 weeks of work through a large scale planning session. To understand PI Planning properly we need to first take a step back and understand three key terms; SAFe, Agile Release Trains and Program Increments.

What is a Sprint in Scrum/Agile?

Chris Adams — Mon, 11 Nov 2019 17:28:00 GMT

A sprint is a short, defined period of time that a team uses to organize their work cycles - it is the key feature of Scrum (the most popular Agile framework) and is used by thousands of teams around the world.

Sprints last between one and four weeks, but two week long sprints are the most common. Throughout this article I’m going to refer to two week long sprints for the sake of simplicity.

Sprints start with defining the goal and scope. This shouldn’t change during the sprint, once it has been defined. The team then go about completing the tasks of the sprint. By the end of the sprint the aim is for the team to have completed everything to achieve their goal.

How are personas used in requirements elicitation on agile projects?

Chris Adams — Sun, 13 Oct 2019 22:30:00 GMT

A persona is a description of a fictional person, representing key characteristics of a specific user class or group. Personas provide models of the user community that make it easier for project teams to understand and predict how users will act and react, based on characteristics such as age, education, knowledge, and attitudes.

A key purpose that personas serve on agile projects is in the formulation of user stories, so that each story is written from the perspective of a distinct person with known attributes – rather than a generic “user” or job role.

Personas are also invaluable in making design decisions, and determining how usability can be optimized for the user community.

As with all other aspects of Agile projects, personas should be developed collaboratively amongst the team and refined iteratively over the course of the project.

Here is a short video that highlights the need to validate personas against real data and real user information, as well as the benefits of building personas iteratively as more information becomes known – The Secret to Developing Effective Personas.

--
Sandy Lambert
Business Architect
LinkedIn Profile

How do you define Agile?

Chris Adams — Sun, 07 Jul 2019 15:50:00 GMT

Agile is a general term and conceptual framework used to describe a number of “light-weight” methodologies, such as Extreme Programming (XP), SCRUM, and Rapid Application Development (RAD), which exhibit a series of common characteristics.

What is Water-Scrum-Fall?

Chris Adams — Sun, 10 Mar 2019 20:43:00 GMT

Water-Scrum-Fall is a term first coined by Forrester to describe the reality of the current state of Agile as it exists in many organizations today. It's hybrid approach to application lifecycle management that combines elements of both Waterfall and Scrum development methodologies.

What is DevOps and how does it relate to software development?

Chris Adams — Sun, 10 Mar 2019 16:42:00 GMT

As the name suggests, DevOps represents a union of two different sub-disciplines – Development and Operations. Most analysts are highly familiar with the Development portion of DevOps. This is the traditional software development lifecycle used to create or make major changes to software applications. It includes a vast network of people who assist in developing a product including product managers, business analysts, software developers, quality assurance engineers, and others. From the DevOps perspective, this stage end just prior to software release/deployment.

The Operations portion of DevOps tend to be less familiar to analysts. In years past Development and Operations operated almost entirely in their own silos. The Ops team is made up of system and network engineers, DBAs, and others that build, manage, and monitor the IT infrastructure required to ensure the software can be properly deployed and supported. They receive the tested software builds and manage the release and deployment of the software onto the IT network while monitoring network stability.

What are Story Points and why use them?

Chris Adams — Sun, 14 Oct 2018 16:40:00 GMT

Story points are a unit of measure used to estimate the relative size and complexity of user stories in agile development. If one user story is 1 point and another is 2 points then the 2 point user story is expected to take twice as much effort to develop as the first.

What is Planning Poker?

Chris Adams — Sun, 14 Oct 2018 16:25:00 GMT

Planning Poker is a consensus-based technique for estimating effort. It is primarily used in agile development to estimate the size of user stories, but can be equally as powerful for estimating effort of key tasks in a project plan using a traditional work breakdown structure.

What is a canary release and what are some of the benefits?

Chris Adams — Sun, 13 May 2018 23:48:00 GMT

A canary release is a technique used to mitigate the risk associated with rolling out new code and functionality to everyone by making the new release only available to a small group of end users. Due to the smaller size of the user group, the impact of the new release is relatively small. If it's determined that bugs exist or that the new functionality or new design isn't well received then it's easy to rollback.

What is a Minimum Viable Product?

Chris Adams — Mon, 12 Mar 2018 17:05:00 GMT

A Minimum Viable Product (MVP) refers to a product that has just enough features to reasonably demonstrate its viability to a group of stakeholders in order to receive feedback. By greatly limiting the scope of the product to its absolute minimum feature set the product development team is able to limits costs and risks.

How does the Business Analyst role change on an Agile project compared to projects using other software development methodologies?

Chris Adams — Mon, 12 Mar 2018 15:02:00 GMT

The role of the BA should actually change very little between different software development methodologies, although the tools and techniques used by the BA can vary according to the needs and attributes of any given project or development lifecycle.

The core responsibilities of a BA on a software development project include requirements elicitation, requirements analysis and requirements management – regardless of the project methodology. The type and format of requirements documentation are just tools, and a good BA has a wide range of tools at his or her disposal.

How are non-functional requirements defined and managed on Agile projects?

Chris Adams — Mon, 12 Mar 2018 14:55:00 GMT

Non-functional requirements (NFRs) are typically defined as backlog constraints on an Agile project, and are managed as part of both product backlog and scrum backlog. They are revisited as part of the ‘Definition of Done’ for each iteration or sprint. If the system does not meet any given NFR, that NFR may spawn new backlog items such as refactors or performance enhancements.

What is Gherkin and how can it help the business analyst?

Chris Adams — Mon, 09 Oct 2017 17:52:00 GMT

Gherkin is a structured natural language that is used by business analysts to specify how they want the system to behave for given scenarios. The Gherkin language is simple. It uses about 10 keywords (Given, When, Then, And, But, Scenario, Feature, Background, Scenario Outline, Examples) which allow the language to be read and parsed by an automation tool called Cucumber.

Describe the life cycle of a User Story?

Chris Adams — Mon, 09 Oct 2017 15:20:00 GMT

User Stories are used by agile methodologies to capture the functionality that a system or software should support. For details about what a user story is and how to write one reference What are User Stories.

What is The Agile Extension to the BABOK® Guide?

Chris Adams — Mon, 12 Jun 2017 14:20:00 GMT

The Agile Extension to the BABOK® Guide was collaboratively developed by the Agile Alliance and IIBA. It builds on the content of the BABOK® Guide as it was first developed by the IIBA and it further extends it to incorporate Agile Development principles.

How can the acronym INVEST assist the analyst during the development of user stories?

Chris Adams — Sun, 12 Feb 2017 11:56:00 GMT

INVEST is an acronym that can help a Product Manager or Developer create quality user stories. INVEST stands for Independent, Negotiable, Valuable, Estimable, Sized-Appropriately, Testable.

I - Independent: The user story should be self-contained if at all possible to avoid dependencies on other user stories. Since one characteristic of agile methodologies is the ability to be flexible and re-prioritize what’s important, independent user stories allow for flexibility during iteration planning. If you do find that your user stories are dependent upon one another, you may be able to combine smaller user stories together that have a dependency between one another. Similarly, you can divide larger dependent user stories into smaller stories such that one of the new smaller stories contains and isolates the overlapping portion of the larger stories.

N - Negotiable: User stories can always be changed or rewritten up until the point of coding. This further supports the flexibility associated with agile methodologies. Since requirements often evolve or rise and fall in priority, user stories should be able to adapt with the changing requirements.

V - Valuable: A user story represents a goal of an end user or purchaser and should deliver functionality that is deemed valuable. This means that specifics of the technical design are not something that you would document as user stories. However, some technical requirements have a component which is valuable to a user. A user might expect pages to load within 2 seconds. The user story would specify the need for 2 second page load times while the specifics of the physical implementation of this would be left out.

E - Estimable: You should always be able to estimate the size of a user story. Sometimes, developers won’t have the experience required to size a particular situation or needed for a user story. When this occurs the user story can be split into two separate user stories. The first is a “spike” which is where developers do some quick research to determine the feasibility of something or get a better idea of how long it might take to implement the particular feature. The spike is always time-boxed, meaning it is limited to a pre-defined amount of time. The “spike” user story might be named “Research (something) to determine…)”, while the second user story is where the functionality will actually be delivered. These two user stories should be scheduled into two separate iterations such than the spike can be completed and the feasibility of the second user story assessed before coding begins. This gives the team time to react if problems arise from the spike.

S - Sized Appropriately: User stories shouldn’t be too big or too small. So how do you decide what size is right. First, any user story that can’t be completed by a developer within a single iteration (or by a developer pair when paired programming is being used) is too big. The user story should be subdivided into two or more smaller stories. Similarly, there is no need to make user stories too granular just for the sake of decomposing features. If features group well together and complement each other then it makes sense to make a single user story. For instance, “As a job seeker I want to be able to add, delete, and edit a job skill on my electronic resume so that I can maintain an accurate listing of my skills.” There is no reason to split “add, delete, and edit” into multiple user stories unless one of them creates a significant amount of work that would make the user story too large for the iteration.

T - Testable: User stories must be testable in order to ensure that development is complete and has been done correctly. So when are user stories not-testable? Often, if the analyst isn’t carful, non-functionality requirements are written in a manner which is un-testable. Consider the example, “pages should always load quickly”. There are two un-testable components of this statement; “always” and “quickly”. A testable statement would be “pages should load within 1.5 seconds 97% of the time”.

--
Chris Adams
LinkedIn Profile

What is SAFe - Scaled Agile Framework?

Adrian M. — Mon, 08 Feb 2016 07:09:00 GMT

SAFe, Scaled Agile Framework, is a collection of best practices and proven success patterns for defining and implementing agile software development processes at enterprise scale. The creator of SAFe is Dean Leffingwell, who was also behind the Rational Unified Process (RUP).

SAFe helps manage the agile software product development process at the enterprise level by organizing the knowledge and best practices at four different levels which build upon each other:

Portfolio Level
Value Stream Level
Program Level
Team Level

In the language of the Scaled Agile Framework, there are 2 variants to consider in a given organization's quest of implementing an agile framework:

4-Level SAFe - Includes all of the four levels above and is suitable for very large solutions with hundreds of team members per value stream.
3-Level SAFe - Does not include the Value Stream level (as it assumes only one value stream) - it is mostly suitable for smaller teams and programs of 100 people or less.

Here's the big picture view of the Scaled Agile Framework (SAFe), including all four level:

The SAFe Portfolio Level provides the tools, roles, and techniques used to organize an enterprise around the agile principles. This level includes the governance, budgeting, and the management of value stream in order to meet the organization's strategic objectives. At the portfolio level, the enterprise strategy is represented by the Portfolio Backlog containing Business Epics.

The SAFe Value Stream Level was designed to be used by very large organizations which multiple and complex value streams. This level allows strategic goals of disparate parts of the organizations to be deal with independently while, at the same time, allowing for the management of complex inter-dependencies and constraints. At the value stream level, the upcoming prioritized work is represented by the Value Stream Backlog containing Capabilities.

The SAFe Program Level is where value is delivered in support of the larger enterprise strategic objectives. This is the level where the product development is coordinated among various Agile Release Trains (ART) concept of continuously delivering value as part of a given program initiative. At the program level, the upcoming prioritized work is represented by the Program Backlog containing the prioritized Features.

The SAFe Team Level is where the agile development take place using agile teams of practitioners use ScrumXP, Team Kanban, or other agile methodology to delivery value at a set cadence via iterations (typically every 2 weeks). As is common with most agile practices, the team level's prioritized work is captured in the form of a Team Backlog containing prioritized User Stories.

What is a Daily Scrum Meeting?

Chris Adams — Sun, 07 Feb 2016 17:50:00 GMT

The Daily Scrum Meeting, sometimes also called a Daily Standup Meeting, is a brief status meeting where a team (ideally around 6-9 members) meets and updates one another on the work that has been completed and what will be completed next. It provides an update to the entire team while providing a daily refocus for each team member as they deliver their status.

What is a Burn Up Chart and how does it differ from a Burn Down Chart?

Chris Adams — Sun, 10 Jan 2016 22:49:00 GMT

A Burn Up Chart is a tool used to track how much work has been completed, and show the total amount of work for a project or iteration. It’s used by multiple software engineering methods but these charts are particularly popular in Agile and Scrum software project management. The completed work and total work is shown on the vertical axis in whatever units a project team feels works best, i.e., work-hours, work-days, story points, or any other work unit. The horizontal access displays time, usually in days, weeks, or iterations (sprints).

What is a Burndown Chart?

Chris Adams — Sun, 10 Jan 2016 19:30:00 GMT

A Burndown Chart is a tool used by multiple software engineering methods to track the progress of work completed. It compares the amount of work remaining (typically measured along the vertical axis) against time (measured along the horizontal axis). The amount of work remaining can be measured in whatever way works best for the project, i.e., work-hours, work-days, story points, or any other work unit. Similarly the time axis can be measured using a variety of units, the most common being days or iterations. The burndown chart gives a quick view of the amount of work that is completed over time.

By I8abug (Own work) [CC BY-SA 3.0]

When applied to Agile methods such as Scrum, this tool can be used to track progress at the Sprint level (a specific iteration of development) or at the release level (multiple iterations that deliver the total functionality for a product release). After the amount of work completed has been measured over several units of time, the burndown chart can be used to forecast the completion of an overall release or project.

--
Chris Adams
LinkedIn Profile

How does the term Velocity apply to an agile project?

Chris Adams — Sun, 10 Jan 2016 17:00:00 GMT

The Velocity of an agile project describes the speed, in story points, at which user stories are completed from sprint to sprint. Formulaically, this is the ratio of completed story points over the duration of the sprint.

Velocity = Completed Story Points / Sprint

Example: If a team completes 150 story points over the course of 3 sprints then the average Velocity = 150/3, or 50 Story Points/Sprint.

Pretty straight forward. So how is velocity useful?

Calculating the team’s velocity after the first sprint provides the information necessary to assign user stories to future sprints, as well as estimate the time required to complete all of the sprints required to deliver the desired functionality. The team velocity can also be used as a starting benchmark from which improvements in team efficiency can be made. This may be by removing friction within processes or team dynamics, or by eliminating or improving on any number of other things which slow the rate of progress

--
Chris Adams
LinkedIn Profile

How do you avoid requirement conflicts while making changes to an existing system where no documentation exists?

Chris Adams — Sun, 13 Dec 2015 20:41:00 GMT

Companies with small IT departments or analysis teams often lack a well defined analysis process. It's not uncommon for analysts to be hired onto a team and find that they are being asked to assist with requirements and new features for a system where no documentation exists. In this case, the analyst needs to create a minimal amount of documentation retroactively.

What are User Stories?

Chris Adams — Sun, 13 Dec 2015 16:00:00 GMT

Extreme Programming (XP), one of many Agile methods, introduced the practice of User Stories to describe what a system or piece of software should do. User stories have since been adopted by many of the agile methods used today.

User Stories are short descriptions of functionality that will be valuable to a user or purchaser of the software or application. They describe the users’ goals when using the system. The initial descriptions can be written by the users, customers, product managers, or developers, and are just a few sentences at most (1-3 sentences being typical). This isn’t the entire user story, but it is all that is created at first.

The development of user stories occurs in three parts; the Card, the Conversation, and the Confirmation.

The Card: Named for the standard index cards on which a user story is often captured, Cards include the brief description of the user story, its relative size to other user stories (called story points), and the priority of the functionality. The cards are used for planning the work that will be completed during each iteration of development. If the size of the user story gets too big to complete within a single iteration then it should be broken into smaller stories. The term used to describe a user story which needs to be further broken down into smaller stories is an “Epic”.
The Conversation: While the conversation itself is not an actual deliverable, it is a critical step in the user story development process. Discussions about each user story are had with the users/customers of the system to flesh out details. The details of the conversations are documented in the form of acceptance tests called “The Confirmation”.
The Confirmation: Acceptance tests are details which are captured from the Conversation that can be used to verify that the user story has been successfully implemented. When index cards are used, the acceptance tests are typically written on the back of the card itself. Acceptance tests can and should be captured whenever they are thought of, however, at the beginning of each iteration there is a defined period of time which is set aside to generate acceptance tests.

Using these three parts, the goal of the user story is to plan which functionality will be developed during each iteration, provide enough detail that a developer pretty much understands what needs to be coded, and provide a means to verify that they have achieved the goal. If the developer needs more details, more conversations are had, the details of which are documented as more acceptance tests.

Here are some sample user stories (the Card) for a job board:

I want to post a resume
I want to search for a job
I want to electronically submit my resume for jobs I like

Some user stories follow a more formal structure than others. One formal approach suggested by Mike Cohn follows the structure: “As a (role) I want (something) so that (benefit)”. At first, structuring your user story descriptions like this may seem like overkill sometimes, but it makes sure that you aren’t forgetting WHO you are designing the functionality for and WHY.

As a job seeker I want to post my resume so that recruiters and employers can find it.
As a job seeker I want to search for a job so that I’m in control of my job search.
As a job seeker I want to electronically submit my resume for jobs I like so that I increase the changes of receiving an interview.

Here are some acceptance tests for the user story, “I want to search for a job”

Test with keyword, salary, and location search parameters
Test that the search results are returned in 2 seconds or less

Some comparisons can be made between user stories and use cases, but there are key differences that should be remembered.

Size and Scope	User Stories have limited scope to fit within an iteration.	Use Cases are almost always larger in scope than user stories.
Structure	User Stories typically represent a single scenario or path through a use case. This could be the main scenario, or an alternative or extension path. Remember that the user story includes the acceptance tests which often describe the details covered in alternative and extension flows.	Use Cases represent a series of related user scenarios. While a main scenario (often the most common scenario) is selected, there are many decision points throughout the flow that branch into alternative or exception flows.
Purpose	User Stories are created to facilitate conversation between the client and development team when the time is right, and have the primary purpose of supporting release and iteration planning process. They are never referred back to as a contract between teams.	Use Cases are written to be understood by both the client and the technology team. They represent a written contract of the desired functionality.
Completeness	User Stories are intentionally written at a goal level initially with just enough detail to describe the user story with just a few sentences at most. Only once the iteration planning begins and more detail will be required the team has conversations to capture acceptance tests.	Use Cases are completed in their entirety early in the analysis and design process. Because of this there exists a natural urge by the customers to place screen specific elements in the use cases themselves, even though there is usually a very strong push by the technology team to try and avoid this. Inevitably the technology team rarely succeeds in keeping UI features out of the use cases.
Longevity	Typically User Stories are not intended to live beyond the iteration in which they are developed. Once the functionality has been developed they are discarded.	Use Cases are often saved and become permanent artifacts representing a permanent contract between the customer and development team.

--
Chris Adams
LinkedIn Profile

What is an epic, and what purpose does it serve on an Agile project?

Chris Adams — Fri, 09 May 2014 14:58:00 GMT

Business epics are large, typically cross-cutting initiatives that encapsulate new development needed to realize certain business benefits. One or more epics can form the basis for the business case that justifies and initiates a project.
Epics are often used as placeholders for new ideas that have not been thought out fully, or whose full elaboration has been deferred until actually needed. Epics are then evolved into split into multiple user stories that help Agile development teams effectively manage and groom their product backlog.

--
Sandy Lambert
Business Architect
LinkedIn Profile

What is a SCRUM backlog?

Chris Adams — Thu, 06 Feb 2014 20:32:00 GMT

There are two types of backlogs in SCRUM that are similar in structure, but differ in purpose and level of detail.

The product backlog lists the requirements for the project in the form of user stories, prioritized by highest customer value. It is managed by the product owner, and is updated over the course of the project as requirements are gathered and refined. It contains sufficient detail for the project team to provide relative estimates to develop, typically based on story points. The product backlog is generally updated on a weekly basis.

At the beginning of each sprint, the team reviews the prioritized product backlog and identifies the customer's highest‐priority user stories that can be completed within the sprint period. These stories become the sprint backlog for that particular sprint. The product backlog is created once and maintained over the life of the project; whereas a new sprint backlog is created at the start of each sprint. The sprint backlog is managed by the project team, and contains a detailed list of all the tasks that the team must complete for the user stories in the sprint. The sprint backlog is reviewed and updated on a daily basis.

--
Sandy Lambert
Business Architect
LinkedIn Profile